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Introduction 


Overview 


If  you  suspect  or  have  been  notified  that  your  computer  system  has  been  or  is 
under  attack,  you  must  determine: 

•  if  there  really  is  or  was  an  attack 

•  if  the  attack  was  successful 

•  and,  to  what  degree  the  attack  compromised  the  system 

This  can  be  routine,  quite  challenging,  or  extremely  difficult.  Modern  operating 
systems  are  large,  complex,  and  imperfect  dynamic  systems,  with  many  places 
for  attackers  to  hide  and  many  opportunities  for  them  to  cover  their  tracks. 

CIAC  has  collected  and  developed  techniques  to  discover  traces  of  an  attack. 
Almost  all  attacks  leave  detectable  remnants  that  may  be  uncovered  and  used  in 
an  investigation. 
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Introduction,  continued 


What’s  in 
This  Guide 


Other 

Situations 


This  document  contains  step-by-step  instructions  to  follow  if  you  are 
investigating  an  actual  security  incident.  It  can  also  be  used  as  a  tutorial  in 
general  techniques  for  use  if  an  attack  occurs. 


This  guide  helps  you  with 
these  security  scenarios... 

By  providing  you  with 
detailed  information  on 
these  topics... 

A  person’s  system  is  linked  to  the 
Internet;  there  is  “a  feeling”  that 
something  is  wrong.  A  security 
problem  might  exist,  but  you  can’t  be 
sure. 

You  are  notified  by  CIAC  that 
someone  from  another  site  that  had  an 
intruder  found  your  site’s  name  in  an 
intruder’s  log  file.  You  know  that  an 
intruder  has  at  least  “touched”  your 
system.  The  extent  of  the  contact  is 
unknown. 

•  displaying  the  users  logged  in  to 
your  system 

•  displaying  active  processes 

An  incident  response  team  informs 
you  that  an  intruder  was  located,  and 
the  team’s  log  files  indicate  the 
intruder  came  from  your  site. 

•  finding  the  footprints  left  by  an 
intruder 

You  get  a  call  that  someone  is 
performing  an  illegal  action  (either 
breaking  into  another  system,  or 
breaking  into  that  particular  system) 
right  NOW.  Action  must  be  swift  in 
order  to  minimize  damage. 

•  detecting  a  sniffer 

•  finding  files  and  other  intrusions 
left  by  an  intruder 

You  suspect  you  have  a  sniffer  on 
your  system,  but  don’t  have  the 
slightest  idea  where  to  start  looking 
for  it. 

This  guide  will  help  you  investigate  the  situations  described  above.  However, 
additional  scenarios  can  occur.  If  your  experience  doesn’t  quite  fit  any  of  the 
situations  listed,  call  CIAC  at  (510)  422-8193  for  assistance. 
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Displaying  the  Users  Logged  in  to  Your 

System 


Overview 


The  “w” 
Command 
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If  you  suspect  that  there  is  an  active  intruder  on  your  system,  first  determine 
where  they  are  and  what  they  are  doing.  This  section  shows  you  how  to  use 
these  commands  to  find  out  who  is  on  your  system: 

•  the  “w”  command 

•  the  “finger”  command 

•  the  “who”  command 


These  commands  are  only  useful  when  a 
suspected  intruder  is  logged  in  to  your  system. 


The  “w”  command  gives  you  a  general  overview  of  all  users  and  their  active 
programs  on  the  system.  A  sample  output  is  shown  here. 


Prompt  % 

w 

3 : 47pm 

up  18 

days,  3:02, 

7  users. 

load 

average : 

0.02,  0.00,  0.00 

User 

tty 

login@ 

idle 

JCPU 

PCPU 

what 

userl 

ttypO 

25Mar94 

2:08 

39:15 

4 

-tosh 

user2 

ttypl 

5Apr94 

8 

5:51 

5:28 

emacs 

user2 

ttyp2 

3 : 4  6pm 

w 

users 

ttypS 

Mon  2pm 

2:04 

1 

-csh 

users 

ttyp4 

Mon  3pm 

41 

21 

-csh 

user2 

ttyp6 

5Apr94 

3 

1:38 

6 

-tosh 

user2 
Prompt  % 

ttyp7 

Wed  2pm 

5:31 

17 

1 

-tosh 

The  first  line  displayed,  the  status  line,  gives  general  information:  the  present 
time,  how  long  the  system  has  been  running,  and  the  load  on  the  system  for 
various  periods  of  time.  The  rest  of  the  output  from  the  “w”  command  shows 
you  who  is  currently  logged  in  to  the  system,  which  TTY  they  are  using,  and 
what  each  user  is  currently  doing. 


Unix  Incident  Guide  CIAC-2305  3 


Displaying  the  Users  Logged  in  to  Your  System,  continued 


The  “finger” 
Command 


What  to  Look  Verify  that: 

For 

•  all  users  are  valid 

•  users  have  not  been  logged  in  for  an  abnormal  length  of 
time 

•  users  are  not  running  suspicious  software 


Vulnerabilities  The  output  listing  from  the  “w”  command  can  be  easily 
modified  to  hide  a  skilled  intruder’s  existence  on  the 
system. 


Another  command  that  displays  who  is  on  the  system  is  the  “finger”  command. 
A  sample  output  is  shown  here. 


Prompt 

%  finger 

Login 

Name 

TTY 

Idle 

When 

Where 

userl 

user  name 

po 

26 

Fri 

11:46 

hostl . sub . domain 

user2 

user  name 

pi 

S4 

Tue 

10:42 

host2 . sub . domain 

user4 

user  name 

p2 

Mon 

14:04 

hosts . sub . domain 

users 

user  name 

pS 

44 

Mon 

14:06 

hosts . sub . domain 

user2 

user  name 

p4 

Mon 

16:4S 

host4 . sub . domain 

user2 

user  name 

p6 

S:45 

Tue 

11:06 

hosts . sub . domain 

user2 

user  name 

P7 

1 

Wed 

14:47 

hosts . sub . domain 

users 

user  name 

p8 

S:04 

Thu 

11:04 

hosts . sub . domain 

users 

user  name 

p9 

1:02 

Fri 

1S:52 

hosts . sub . domain 

Prompt 

% 

The  “finger”  command  shows  you  who  is  currently  logged  in  to  the  system, 
which  TTY  they  are  using,  the  time  they  logged  in,  and  where  they  are  logged 
in  from. 


What  to  Look  Verify  that: 

For 

•  all  users  are  valid 

•  users  have  not  been  logged  in  for  an  abnormal  length  of 
time 

•  the  login  location  of  each  user  is  valid 


Vulnerabilities  The  output  from  the  “finger”  command  can  easily  be 
modified  to  hide  a  skilled  intruder’s  existence. 
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Displaying  the  Users  Logged  in  to  Your  System,  continued 


The  “who” 
Command 


12/12/94 


The  “who”  command  lists  information  about  the  users  currently  on  the  system. 
This  information  is  retrieved  from  the  /etc/utmp  file.  A  sample  output  is  shown 
here. 


Prompt 

%  who 

userl 

ttypO 

Mar 

25 

11:46 

(hostl . sub .domain) 

user2 

ttypl 

Apr 

5 

10:42 

(host2 . sub. domain) 

user4 

ttyp2 

Apr 

18 

14:04 

(hosts . sub .domain) 

users 

ttypS 

Apr 

11 

14:06 

(hosts . sub .domain) 

user2 

ttyp4 

Apr 

18 

16:4S 

(host4 . sub. domain) 

user2 

ttyp6 

Apr 

5 

11:06 

(hosts . sub. domain) 

user2 

ttyp7 

Apr 

6 

14:47 

(hosts . sub. domain) 

users 

ttyp8 

Apr 

14 

11:04 

(hosts . sub .domain) 

users 

Prompt 

ttyp9 

Apr 

15 

IS:  52 

(hosts . sub .domain) 

This  command  lists  who  is  currently  logged  in  to  the  system,  which  TTY  they 
are  using,  login  time,  and  where  they  are  logged  in  from. 


What  to  Look  Verify  that: 

For 

•  all  users  are  valid 

•  users  have  not  been  logged  in  for  an  abnormal  length  of 
time 

•  the  login  location  of  each  user  is  valid 


Vulnerabilities  The  output  from  the  “who”  command  can  easily  be 
modified  to  hide  a  skilled  intruder’s  existence,  as  the 
command  gets  its  information  from  the  /etc/utmp  file. 
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Displaying  Active  Processes 


Overview  Even  if  an  intruder  is  no  longer  logged  in  to  a  (potentially)  penetrated  system,  a 

process  may  have  been  left  running  by  the  intruder  to  continue  performing 
tasks.  This  section  shows  you  how  to  use  these  commands  to  display  the  active 
processes  running  on  your  system: 

•  the  “ps”  command 

•  the  “crash”  command 


The  “ps  -agux”  command  lists  the  processes  that  are  executing  on  your  system. 

•  The  command’s  “a”  parameter  displays  all  processes  running  on  the 
system,  not  just  those  owned  by  you. 

•  The  command’s  “g”  parameter  displays  all  processes,  as  opposed  to  those 
which  “ps”  decides  are  simply  “interesting”  (refer  to  the  “ps”  man  page  for 
the  definition  of  “interesting”). 

•  The  “u”  parameter  displays  user-oriented  output. 

•  The  “x”  parameter  includes  processes  without  control  terminals. 

The  “ps”  command  is  a  reliable  way  to  see  what  programs  are  being  executed 

on  the  system.  A  shortened  sample  output  is  shown  here. 


Prompt 

%  ps  —agux 

USER 

PID 

%CPU 

%MEM 

sz 

RSS 

TT 

STAT 

START 

TIME 

COMMAND 

users 

28206 

8.1 

0.4 

48 

280 

p4 

S 

13:SS 

0 

00 

man  inetd.conf 

users 

28208 

3.9 

0.5 

56 

312 

p4 

S 

13:SS 

0 

00 

more  -s  /usr/man/cat5/in 

root 

2 

0.0 

0.0 

0 

0 

7 

D 

Mar  2S 

0 

02 

pagedaemon 

root 

87 

0.0 

0.0 

176 

0 

7 

IW 

Mar  2S 

0 

16 

sendmail:  accepting  conn 

root 

1 

0.0 

0.0 

56 

0 

7 

IW 

Mar  2S 

0 

04 

/sbin/init  - 

userS 

15547 

0.0 

0.0 

88 

0 

7 

IW 

Apr  S 

0 

00 

selection_svc 

user  1 

184 

0.0 

0.0 

192 

0 

pO 

IW 

Mar  2S 

0 

06 

-tcsh  (tcsh) 

user2 

28209 

0.0 

0.8 

208 

520 

p5 

R 

13:SS 

0 

00 

ps  -agux 

user2 

21674 

0.0 

0.4 

112 

248 

p5 

S 

16:24 

0 

00 

-tcsh  (tcsh) 

userS 

16834 

0.0 

0.0 

88 

0 

7 

IW 

Apr  S 

0 

00 

selection_svc 

userS 

27350 

0.0 

0.0 

112 

0 

P3 

IW 

Apr  11 

0 

01 

-csh  (csh) 

user4 

23846 

0.0 

0.0 

80 

0 

pa 

IW 

11 : 12 

0 

00 

-csh  (csh) 

userS 

23801 

0.0 

0.0 

80 

0 

p8 

IW 

11:04 

0 

00 

-csh  (csh) 

user2 

18590 

0.0 

0.0 

120 

0 

P3 

IW 

Apr  6 

0 

01 

-tcsh  (tcsh) 

user2 

15591 

0.0 

0.0 

120 

0 

p6 

IW 

Apr  S 

0 

06 

-tcsh  (tcsh) 

user2 

15588 

0.0 

0.1 

9288 

72 

pi 

I 

Apr  S 

7 

08 

emacs 

user2 

15496 

0.0 

0.0 

112 

0 

pi 

IW 

Apr  S 

0 

00 

-tcsh  (tcsh) 

Prompt  % 


The  “ps” 
Command 
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Displaying  Active  Processes,  continued 


The  “crash” 
Command 


What  to  Look  The  following  may  indicate  undesired  activity: 

For 

•  processes  that  take  a  long  time 

•  unusual  start  times  (such  as  3:00  a.m.) 

•  unusual  names 

•  a  process  that  has  an  extremely  high  percentage  of  CPU 
(this  may  indicate  a  sniffer  process) 

•  processes  without  a  controlling  terminal  (a  “?”  in  the 
TT  column)  that  are  executing  unusual  programs 


Vulnerabilities  In  some  cases,  compromised  systems  have  been  found  to 
contain  a  Trojaned  version  of  “ps”  which  does  not  display 
intruder  processes.  Also,  if  an  invalid  process  is  running 
but  has  a  valid  process  name,  it  may  be  difficult  to 
distinguish  the  suspicious  process.  For  example,  intruders 
often  run  sniffer  processes  under  names  such  as  “sendmail” 
or  “inetd”. 


You  can  use  the  “crash”  command  to  list  all  processes.  This  functions  as  a 
cross-check  against  the  “ps”  command.  That  is,  finding  a  process  with  “crash” 
output  that  does  not  appear  in  “ps”  output  (matching  pids).  Once  you  execute 
“crash,”  you  will  receive  a  “>”  prompt.  Type  proc  in  response  and  quit  when 
you  are  finished  running  “crash”. 


Prompt  %  crash 

dumpfile  =  /dev/mem,  namelist  =  /vmunix,  outfile  =  stdout 

>  proc 

PROC  TABLE  SIZE  =  522 


SLOT 

ST 

PID 

PPID 

PGRP 

UID 

PRI 

CPU 

EVENT 

NAME 

ELAGS 

0 

s 

0 

0 

0 

0 

0 

0 

£8172698 

load  sys 

1 

s 

1 

0 

0 

0 

30 

0 

f82b5494 

init 

load  pagi 

2 

s 

2 

0 

0 

0 

1 

0 

f82b5550 

load  sys 

3 

s 

965 

141 

965 

0 

26 

0 

£8172158 

in . rlogind 

swapped  pagi 

4 

s 

56 

1 

56 

0 

26 

0 

£8172158 

portmap 

swapped  pagi 

6 

s 

59 

1 

42 

0 

26 

0 

£8172158 

keyserv 

swapped  pagi 

7 

s 

11039 

1 

11039 

0 

28 

0 

££12a2d0 

getty 

swapped  pagi 

8 

s 

73 

1 

73 

0 

26 

0 

£8172158 

in . named 

load  pagi 

9 

s 

76 

1 

75 

0 

26 

0 

£8152d2c 

biod 

load  pagi 

10 

s 

77 

1 

75 

0 

26 

0 

£8152d2c 

biod 

load  pagi 

11 

s 

78 

1 

75 

0 

26 

0 

£8152d2c 

biod 

load  pagi 

12 

s 

79 

1 

75 

0 

26 

0 

£8152d2c 

biod 

load  pagi 

13 

s 

90 

1 

90 

0 

26 

0 

£8172158 

syslogd 

load  pagi 

14  s 

>  quit 

Prompt 

98 

1 

98 

0 

26 

0 

££648d2e 

sendmail 

load  pagi 
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Displaying  Active  Processes,  continued 


What  to  Look 
For 


Vulnerabilities 


The  following  may  indicate  undesired  activity: 

•  processes  that  do  not  appear  in  the  ps  list  (use  the  PID 
column  to  identify) 

•  a  high  value  in  the  CPU  column 

•  unusual  commands  in  the  NAME  column 


Names  can  be  faked.  Like  any  command,  “crash”  can  be 
Trojaned. 
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Finding  the  Footprints  Left  by  an  intruder 


Overview 


The  “last” 
Command 


If  you  suspect  that  an  intruder  has  been  on  your  system  but  is  gone,  use  the 
commands  and  files  described  in  this  section  to  find  the  “footprints”  the  intruder 
may  have  left  behind.  This  section  shows  you  how  to  use  these  commands  and 
files: 

•  the  “last”  command 

•  the  “lastcomm”  command 

•  the  “/var/log/syslog”  file 

•  the  “netstat”  command 


The  “last”  command  displays  information  about  logins  and  logouts  on  the 
system  from  the  /var/adn^wtmp  file.  If  you  can  determine  the  username  the 
intruder  used  to  log  in,  this  command  can  show  you  how  long  the  intruder  was 
logged  in  and  where  they  logged  in  from. 

•  The  command’s  “-n”  parameter  is  used  to  display  the  last  n  entries  in  the 
/var/adm/wtmp  file. 

A  sample  output  is  shown  here. 


Prompt 

%  last 

-20 

userl 

ftp 

hostl . sub. domain 

Fri 

AprlS  : 

15:09  -  15:10 

(00:00) 

user3 

ttyp9 

hosts . sub. domain 

Fri 

Apr 

15 

13:52  still  logged  in  1 

user6 

ttYp2 

host 7 . sub. domain 

Fri 

Apr 

15 

13:45  -  14:1 

(00:26) 

user6 

ttYp2 

host 7 . sub. domain 

Fri 

Apr 

15 

10:34  -  10:34 

(00:00) 

user6 

ftp 

host 7 . sub. domain 

Fri 

Apr 

15 

10:32  -  10:33 

(00:01) 

user4 

ttYp4 

hosts . sub. domain 

Fri 

Apr 

15 

10:17  still  logged  in  1 

users 

ttyp2 

hosts. sub . domain 

Fri 

Apr 

15 

09:20  -  10:29 

(01:09) 

userl 

ttyhl 

Thu 

Apr 

14 

20:33  -  22:00 

(01:26) 

user4 

ftp 

hosts . sub. domain 

Thu 

Apr 

14 

14:21  -  14:22 

(00:01) 

user4 

ttYp2 

hosts . sub. domain 

Thu 

Apr 

14 

14:01  -  1S:36 

(02:35) 

user4 

ftp 

hosts . sub . domain 

Thu 

Apr 

14 

13:43  -  13:44 

(00:00) 

users 

ttYp4 

hosts. sub . domain 

Thu 

Apr 

14 

13:38  -  14:56 

(01:18) 

user4 

ttYp2 

hosts . sub. domain 

Thu 

Apr 

14 

13:37  -  13:47 

(00:10) 

user4 

ftp 

hosts . sub. domain 

Thu 

Apr 

14 

13:16  -  13:18 

(00:01) 

user4 

ttYp2 

hosts . sub. domain 

Thu 

Apr 

14 

13:12  -  13:18 

(00:05) 

user4 

ttypa 

hosts . sub. domain 

Thu 

Apr 

14 

11:13  -  15:05 

(03:52) 

user4 

ttYp9 

hosts . sub. domain 

Thu 

Apr 

14 

11:12  -  13:08 

(01:55) 

user3 

ttypS 

hosts . sub. domain 

Thu 

Apr 

14 

11:04  still  . 

logged  in 

userl 

Prompt 

ftp 

hostl . sub. domain 

Thu 

Apr 

14 

11:01  -  11:02 

(00:00) 
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Finding  the  Footprints  Left  by  an  Intruder,  continued 


The 

“lastcomm” 

Command 


The  first  column  contains  the  username,  followed  by  the  terminal  device  the 
user  is  connected  to.  If  the  connection  used  a  network  device,  the  name  of  a 
remote  system  is  displayed  in  the  next  column.  For  serial  devices  such  as  dial¬ 
up  modems,  the  column  will  be  blank.  This  is  followed  by  the  login  and  logout 
time  and  an  indication  of  the  length  of  the  session. 


What  to  Look  •  examine  the  log  entries  made  around  the  time  of  the 
For  suspected  attack  for  ones  that  appear  to  be  out  of  the 

ordinary,  including  logins  to  accounts  that  had 
previously  been  dormant,  logins  from  unexpected 
locations,  logins  at  unusual  times,  and  short  login  times 

•  a  missing  /var/adm/wtmp  file  or  one  with  gaps  in  the 
output  (this  may  indicate  that  an  intruder  attempted  to 
hide  their  existence) 

As  a  general  rule,  many  system  administrators  never  delete 
this  file.  Therefore,  it  can  be  quite  large  and  include  activity 
from  when  the  system  was  first  loaded. 


Vulnerabilities  An  intruder  who  breaks  into  a  system  can  hide  their  tracks 
by  deleting  or  modifying  the  /var/adm/wtmp  file. 


The  “lastcomm”  command  displays  the  last  commands  executed.  This 
command  is  only  available  if  you  have  process  accounting  turned  on.  With  this 
command,  you  can  see  every  command  issued  by  anyone  on  the  system.  A 
sample  output  is  shown  here. 


Prompt  %  lastcomm 


nrof  f 

userl 

ttypl 

0.39 

secs 

Thu 

Sep 

8 

12:31 

man 

userl 

ttypl 

0.00 

secs 

Thu 

Sep 

8 

12:31 

sh 

userl 

ttypl 

0.00 

secs 

Thu 

Sep 

8 

12:31 

page 

userl 

ttypl 

0.03 

secs 

Thu 

Sep 

8 

12:31 

col 

userl 

ttypl 

0.02 

secs 

Thu 

Sep 

8 

12:31 

tbl 

userl 

ttypl 

0.02 

secs 

Thu 

Sep 

8 

12:31 

head 

userl 

ttypl 

0.00 

secs 

Thu 

Sep 

8 

12:31 

lastcomm 

X 

userl 

ttypl 

0.06 

secs 

Thu 

Sep 

8 

12:31 

lastcomm 

X 

userl 

ttypl 

0.05 

secs 

Thu 

Sep 

8 

12:31 

csh 

F 

userl 

ttypl 

0.00 

secs 

Thu 

Sep 

8 

12:31 

lastcomm 

X 

userl 

ttypl 

2.97 

secs 

Thu 

Sep 

8 

12:28 

sh 

root 

0.00 

secs 

Thu 

Sep 

8 

12:30 

at  run 

root 

0.00 

secs 

Thu 

Sep 

8 

12:30 

cron 

F 

root 

0.00 

secs 

Thu 

Sep 

8 

12:30 

sh 

root 

0.00 

secs 

Thu 

Sep 

8 

12:15 

at  run 

root 

0.00 

secs 

Thu 

Sep 

8 

12:15 

cron 

F 

root 

0.00 

secs 

Thu 

Sep 

8 

12:15 

sh 

root 

0.00 

secs 

Thu 

Sep 

8 

12:00 

at  run 

root 

0.00 

secs 

Thu 

Sep 

8 

12:00 

cron 

F 

root 

_ 

0.00 

secs 

Thu 

Sep 

8 

12:00 

Prompt  % 
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Finding  the  Footprints  Left  by  an  Intruder,  continued 


The  /var/log/ 
syslog  File 


12/12/94 


What  to  Look  This  command  is  an  excellent  way  of  seeing  what  a  user 
For  did  while  on  your  system  because  it  lists  all  commands 

executed  by  all  users. 


Vulnerabilities  This  command  produces  a  file  that  tends  to  get  quite  large 
very  quickly  as  it  saves  the  data  needed  to  track  the 
commands  issued  by  every  user.  You  should  periodically 
rename  it  so  that  you  can  manage  smaller  files. 

The  “lastcomm”  command  only  tracks  the  command  that 
ran  a  program,  but  not  what  actions  were  taken  after  the 
program  started  (for  example,  it  may  show  the  editor  being 
run,  but  not  which  files  were  opened  after  the  initialization 
of  the  editor). 

Many  times,  attacks  are  not  discovered  until  days  after  the 
actual  event.  And  in  these  cases,  the  accounting  logs  may 
have  been  purged  by  the  time  the  attack  is  discovered.  The 
biggest  potential  intruder- style  vulnerability  is  that  the  data 
is  kept  in  the  file  /var/adm/pacct,  which  the  intruder  can 
easily  delete  and  perhaps  modify  if  the  proper  privileges 
are  obtained. 


The  /var/log/syslog  file  is  a  file  that  contains  messages  relating  to  various  types 
of  connections  to  your  system.  The  content  of  this  file  is  defined  by  the 
/etc/syslog.conf  file.  The  results  of  this  command  contain  extremely  long  lines; 
a  shortened  sample  of  this  file  is  shown  here. 


Prompt  %  more  /var/log/syslog 

Apr  20  13:04:22  hostS  sendmail [15026] : 

NAA15025 : to=user8@sub . domain, 

user7@sub. domain, user3@sub. domain,  delay=0 0 : 0 0 : 02 ,  mailer=smtp, 
relay=computer . sub . domain .  [ 12 8 . xxx . xx . xx] ,  stat=Sent  (Mail 

accepted) 

Apr  20  13:04:23  host8  sendmail [15026] :  NAA15025: 
to=user5 , user2 ,  delay=00 : 00 : 03,  mailer=local ,  stat=Sent 

Apr  20  13:04:23  host8  sendmail [15026] :  NAA15025: 
to=userl@hostl . sub . domain,  delay=00 : 00 : 03,  mailer=smtp, 
relay=hostl . sub . domain .  [198.128.36.1],  stat=Sent  (Ok) 

Apr  20  13:06:20  host8  in . telnetd [ 15032 ] :  connect  from 
computer . sub . domain  (198. xxx . xx . xx) 

Prompt  % _ 


Unix  Incident  Guide  CIAC-2305  11 


Finding  the  Footprints  Left  by  an  Intruder,  continued 


Most  messages  are  from  the  sendmail  program,  and  display  the  status  of 
messages  sent  and  received  by  your  system.  This  file  may  also  contain  in.telnetd 
connection  messages  and  other  previously  defined  messages. 


•  Since  this  file  saves  data  on  incoming  as  well  as 
outgoing  information,  especially  sendmail  information, 
one  of  the  things  to  look  for  is  outbound  E-mail  to 
suspicious  hosts.  This  may  indicate  that  an  intruder  sent 
out  information  from  your  system  to  a  remote  system. 

•  Telnet  connections,  both  incoming  and  outgoing, 
should  be  examined. 

•  A  short  file  may  be  suspicious,  as  it  may  indicate  that 
this  file  has  been  edited  or  deleted.  A  ‘hole’  in  the  file 
(a  large  chunk  of  time  when  no  messages  occur)  may 
indicate  that  an  intruder  deleted  the  messages  related  to 
their  time  on  the  system.  Note  that  this  ‘hole’  may  be 
useful  in  tracking  down  when  the  intruder  used  the 
system. 

•  In  general,  look  for  things  that  may  appear  out  of  the 
ordinary. 


Vulnerabilities  In  many  cases,  the  /var/log/syslog  file  is  world  writable  and 
must  remain  so  for  operational  reasons.  Therefore,  its  data 
may  be  suspect  and  untrustworthy. 

This  file  tends  to  be  very  long.  Investigating  all 
connections,  especially  sendmail  messages,  can  be  difficult. 
This  is  because  at  least  one  line  is  written  to  the 
/var/log/syslog  file  for  each  mail  message.  In  addition, 
users  tend  to  delete  messages  and  forget  exactly  who  sent 
them  the  messages,  when  they  were  received,  and  what 
they  were  about. 


What  to  Look 
For 
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Finding  the  Footprints  Left  by  an  Intruder,  continued 


The  /var/adm/ 

messages 

File 


The  /var/adm/messages  file  usually  contains  a  listing  of  all  messages  that  are 
sent  to  the  console.  The  actual  content  of  this  file  is  defined  in  the 
/etc/syslog.conf  file.  A  sample  of  this  file  is  shown  here. 


Prompt  %  more  /var/adm/messages 

Mar  21  10:36:04  hostS  su:  'su  root'  failed  for  userl  on 
/dev/ttyp2 

Mar  21  10:36:08  hostS  su:  'su  aaa'  succeeded  for  userl  on 
/dev/ttyp2 

Mar  21  16:00:59  hostS  xntpd[121]:  Previous  time  adjustment 
didn't  complete 

Mar  24  15:01:44  hostS  login:  REPEATED  LOGIN  FAILURES  ON 
console,  user3 

Mar  25  11:42:51  hostS  shutdown:  reboot  by  userl 
Mar  25  11:42:53  hostS  syslogd:  going  down  on  signal  15 
Mar  25  11:48:04  hostS  su:  'su  aaa'  succeeded  for  userl  on 
/dev/ttypO 

Mar  28  15:47:19  hostS  login:  ROOT  LOGIN  REFUSED  ON  ttyp3  FROM 
machine . sub . domain 

Mar  28  16:12:12  hostS  login:  ROOT  LOGIN  console 

Apr  13  15:58:35  hostS  su:  'su  aaa'  failed  for  userl  on 

/dev/ttypO 

Apr  13  15:58:55  hostS  su:  'su  aaa'  succeeded  for  userl  on 
/dev/ttypO 

Apr  15  08:48:22  hostS  named[2682]:  starting,  named  4.9.2  Wed 
Nov  17  13:17:49  PST  1993 

Apr  15  08:48:22  hostS  named[2683]:  Ready  to  answer  queries. 
Prompt  % _ 


What  to  Look  The  following  may  indicate  undesired  activity: 

For 

•  an  unauthorized  user  logging  into  the  root  directory 

•  attempts  to  “su”  to  root  or  a  privileged  account 

•  failed  login  attempts  may  be  from  a  valid  user  making 
mistakes  or  from  an  intruder 

In  the  sample  file  above,  you  would  make  sure  that  “userl” 
is  a  valid  user  logging  into  the  aaa  root  privileged  account. 


Vulnerabilities  Once  an  intruder  obtains  root  access,  this  file  can  be 

modified  or  deleted  quite  easily.  Also,  if  the  syslog.conf 
file  is  compromised,  logging  to  this  file  may  be 
discontinued. 


12/12/94 


Unix  Incident  Guide  CIAC-2305 


13 


Finding  the  Footprints  Left  by  an  Intruder,  continued 


The  “netstat” 
Command 


The  “netstat”  command  displays  listening  and  connected  processes.  You 
should  compare  the  output  from  this  command  with  the  output  from  the 
“last  -n”  command. 

•  The  command’s  “-a”  parameter  is  used  to  display  the  status  of  all  sockets. 
A  sample  output  is  shown  here. 


Prompt 

% 

netstat  -a 

Active 

Internet 

connections  (including  servers 

) 

Proto  Recv-Q  Send-Q 

Local  Address 

Foreign  Address 

(state) 

tcp 

0 

0 

hosts . sub . domain .pop 

hostl . sub . domain .1809 

TIME_WAIT 

tcp 

0 

78 

host 6 . sub . domain . telne 

host  9 . sub . domain .54  64] 

ESTABLISHED 

tcp 

0 

0 

host 6 . sub . domain .telne 

host 7 . sub . domain .1434 

ESTABLISHED 

tcp 

0 

0 

hosts . sub . domain . login 

host 3 . sub . domain .1022 

ESTABLISHED 

tcp 

0 

0 

hosts . sub . domain . login 

host 3 . sub . domain .1023 

ESTABLISHED 

tcp 

0 

0 

hosts . sub . domain . login 

host 5 . sub . domain .1021 

ESTABLISHED 

tcp 

0 

0 

host 6 . sub . domain .telne 

host 5 . sub . domain .1957 

ESTABLISHED 

tcp 

0 

0 

hosts . sub . domain . login 

host 2 . sub . domain .1023 

ESTABLISHED 

tcp 

0 

0 

* . printer 

*  . 

* 

LISTEN 

tcp 

0 

0 

*.731 

*  . 

* 

LISTEN 

tcp 

0 

0 

*.pop 

*  . 

* 

LISTEN 

tcp 

0 

0 

* . chargen 

*  . 

* 

LISTEN 

tcp 

0 

0 

* . daytime 

*  . 

* 

LISTEN 

tcp 

0 

0 

* . discard 

*  . 

* 

LISTEN 

tcp 

0 

0 

* . echo 

*  . 

* 

LISTEN 

tcp 

0 

0 

* .time 

*  . 

* 

LISTEN 

tcp 

0 

0 

* . finger 

*  . 

* 

LISTEN 

udp 

0 

0 

*.1022 

*  . 

* 

udp 

0 

0 

*.1023 

*  . 

* 

udp 

0 

0 

*.16517 

*  . 

* 

udp 

0 

0 

*.16516 

*  . 

* 

udp 

0 

0 

*.16515 

*  . 

* 

udp 

0 

0 

*.772 

*  . 

* 

udp 

0 

0 

*.16514 

*  . 

* 

udp 

0 

0 

*.16513 

*  . 

* 

Active 

UNIX  domain  sockets 

Address 

Type 

Recv- 

-Q  Send-Q  Vnode 

Sonn  Refs  Nextref 

Addr 

ff65340c 

dgram 

0  0  0 

0  0  0 

ff653e8c 

dgram 

0  0  0 

0  0  0 

ff64978c 

dgram 

0  0  0 

0  0  0 

ff648d8c 

dgram 

0  0  ffl51508 

0  0  0 

/dev/log 

ff 64920c 

dgram 

0  0  0 

0  0  0 

ff64808c 

dgram 

0  0  0 

0  0  0 

Prompt 

% 

What  to  Look  The  following  may  indicate  undesired  activity: 

For 

•  you  have  a  telnet  connection  that  does  not  correlate 
with  the  output  from  the  “who”  or  “w”  commands 

•  other  network  connections 


Vulnerabilities  In  some  cases,  compromised  systems  have  been  found  to 
contain  a  Trojaned  version  of  “netstat”  that  does  not  show 
connections  to  or  from  the  source  of  the  intrusion. 
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Detecting  a  Sniffer 


Overview 


The  “ifconfig” 
Command 


Sniffers  are  a  major  source  of  contemporary  attacks.  This  section  shows  you 
how  to  use  the  “ifconfig”  command  to  determine  if  a  sniffer  has  been  installed. 


The  “ifconfig”  command  displays  the  current  configuration  of  your  network 
interface.  Most  Ethernet  adaptors  are  (and  should  be)  configured  to  accept  only 
messages  intended  for  themselves.  An  attacker  must  set  a  computer’s  adaptor  to 
“promiscuous  mode,”  in  order  to  listen  to  (and  record)  everything  on  its 
segment  of  the  Ethernet. 

A  sample  output  of  a  system  in  promiscuous  mode  is  shown  here. 


Prompt  %  ifconfig  -a 

ieO :  flags=63<UP, BROADCAST, NOTRAILERS, RUNNING, PROMISO 

inet  987.654.32.1  netmask  ffffffOO  broadcast  987.654.32.255 
loO :  flags=49<UP, LOOPBACK, RUNNING> 

inet  127.0.0.1  netmask  ffOOOOOO 

Prompt  % 


Note  “PROMISC”  is  the  last  parameter  of  the  flag’s  description. 


What  to  Look  In  conjunction  with  positive  results  from  the  above 
For  command,  the  following  may  indicate  undesired  activity: 

•  newly  created  files 

•  a  process  that  has  an  extremely  high  percentage  of  CPU 


Vulnerabilities  Eike  any  command,  “ifconfig”  can  be  Trojaned.  If  you 

suspect  that  a  sniffer  has  been  installed,  obtain  “cpm”  from 
CIAC  or  CERT  and  run  it.  The  cpm  tool  will  test  the 
network  interface  directly  and  report  if  it  is  in  promiscuous 
mode. 
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Finding  Files  and  Other  Evidence  Left  by 

an  Intruder 


Overview 


What  to  Look 
For 


When  an  intruder  breaks  into  a  system,  information  related  to  the  attack  is 
occasionally  left  behind.  This  information  includes,  but  is  not  limited  to 
directories,  shell  scripts,  programs,  and  text  files. 

This  section  describes  various  files  that  have  been  found  on  compromised 
systems.  Because  file  names  can  be  easily  changed,  the  actual  name  of  the  file 
may  be  different  than  the  file  names  listed  in  this  section.  Many  times,  intruders 
try  to  hide  files;  methods  for  achieving  and  detecting  this  will  be  also  be 
described. 


When  you  look  for  files  left  behind  by  an  intruder,  you  should: 

•  obtain  a  baseline  of  what  your  normal  operating  system  looks  like 

•  find  files  and  file  and  directory  names  commonly  used  by  intruders 

•  examine  system  logs 

•  inspect  log  files 

•  inspect  processes 

•  inspect  targeted  files 

•  look  for  X  windows  intrusions 

Each  of  these  tasks  is  described  on  the  following  pages. 
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Finding  Files  and  Other  Evidence  Left  by  an  Intruder,  continued 


Obtaining  a 
Baseiine  of 
What  Your 
Normai 
Operating 
System 
Looks  Like 


To  obtain  a  baseline  of  your  normal  operating  system,  you  should  periodically 
run  the  commands  described  in  this  document.  Record  and  become  familiar 
with  the  output  from  these  commands.  Also,  obtain  and  periodically  use  SPI  and 
Tripwire. 


Finding  Fiies 

and  Fiie  and 

Directory 

Names 

Commoniy 

Used  by 

Intruders 


The  file  names  given  in  this  section  are  commonly  used  by  intruders.  Start  by 
looking  for  these  file  names,  but  realize  that,  as  intruders  learn  that  their  bogus 
file  names  are  discovered,  they  will  change  them.  You  must  ultimately  look  for 
a  name  or  names  that  do  not  belong. 


Suspicious  Often,  the  best  indication  of  whether  or  not  a  system  has 
Files  been  compromised  comes  from  a  thorough  examination  of 

its  file  systems.  The  creation  or  modification  of  files  is 
often  a  strong  indication  of  intruder  activity  on  a  system. 

Occasionally,  the  intruder  will  modify  (“Trojan”)  system 
programs  to  hide  the  intrusion.  Some  system  administrators 
have  discovered  that  a  command  such  as  “ps”  will  be 
Trojaned  to  ignore  the  intruder’s  processes.  Keep  this  in 
mind  when  running  any  command,  because  if  a  command 
has  been  Trojaned,  the  results  of  the  command  will  be 
questionable. 

The  “find”  command,  run  preferably  as  root,  will  list  all 
files  that  have  been  modified  in  the  previous  n  days: 


Prompt  #  find  /  -mtime  -ndays  -Is 


Note  that  many  intruders  routinely  change  file  modification 
times  to  hide  changes  made  to  the  system.  Many  of  these 
modifications  may  still  be  detected  by  examining  a  file’s 
inode  change  time,  which  is  more  difficult  for  an  intruder 
to  forge.  The  following  command  will  locate  all  files  with 
inode  change  times  that  have  changed  in  the  last  n  days: 


Prompt  #  find  /  -ctime  -ndays  -Is 
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Finding  Files  and  Other  Evidence  Left  by  an  Intruder,  continued 


Hidden  Files 
and 

Directories 


Password 
Files  and 
Crack 


Setuid  Files 


While  examining  the  results  generated  by  the  above 
commands,  consider  the  hidden  files  and  directories  often 
used  by  attackers  described  in  the  next  section,  “Hidden 
Files  and  Directories.” 


Intruders  often  attempt  to  conceal  their  presence  on  a 
system  by  using  hidden  files  or  directories;  that  is,  those 
with  names  that  begin  with  a  (period).  They  are  not 
displayed  by  the  “Is”  command,  unless  the  “-a”  parameter 
is  used.  The  following  names  are  commonly  used  by 
intruders: 

“...”  (period  period  period) 

“..  ”  (period  period  space) 

“..  ”  (period  period  space  space) 

“.hushlogin” 

“.sh” 

“.XX” 

“.test” 


In  many  cases,  intruders  use  compromised  hosts  to  store 
and  crack  password  files  from  other  systems.  Finding  files 
that  contain  password  entries  from  other  systems  or  finding 
password  cracking  software  (such  as  Crack)  probably 
indicates  intruder  activity  on  your  system. 


Unix  systems  allow  users  to  temporarily  elevate  their 
privileges  through  a  mechanism  called  setuid.  When  a  file 
with  the  setuid  attribute  is  executed  by  a  user,  the  program 
is  given  the  effective  access  rights  of  the  owner  of  the  file. 
For  example,  the  “login”  program  is  typically  a  setuid  file 
owned  by  root.  When  a  user  invokes  “login”,  the  program 
is  able  to  access  the  system  with  super-user  privileges 
instead  of  the  user’s  normal  privileges. 

Intruders  often  create  setuid  files  that  enable  them  to 
quickly  gain  root  access  during  later  visits  to  the  system. 
Often,  the  file  is  placed  in  a  hidden  directory  or  has  a 
hidden  filename  (e.g.,  “.sh”). 

Setuid  files  appear  in  directory  lists  with  an  “s”  in  place  of 
the  “x”  in  the  execute  bit  position.  For  example,  the  output 
of  the  “Is  -1  .sh”  command  would  display  output  similar  to 
the  following: 


-r-sr-xr-x  1  root  other  86012  Jun  2  01:09  . sh 


18 


Unix  Incident  Guide  CIAC-2305 


12/12/94 


Finding  Files  and  Other  Evidence  Left  by  an  Intruder,  continued 


Examining 
System  Logs 


Note  that  a  typical  Unix  system  contains  dozens  of 
legitimate  setuid  programs  necessary  for  normal  operation 
of  the  system.  Setuid  files  that  should  be  suspected  include: 

•  files  that  appear  to  have  been  modified  recently 

•  unfamiliar  files 

•  files  stored  in  user  or  temporary  directories 

To  list  all  setuid  files  on  your  system,  use  the  following 
command: 


Prompt  #  find  /  -user  root  -perm  -4000  -print 


All  Unix  systems  provide  some  level  of  accounting,  recording  the  actions  of 
both  users  and  system  processes.  The  amount  of  information  recorded  can  vary 
significantly  depending  on  both  the  version  of  Unix  and  its  configuration.  The 
default  for  many  systems  is  to  record  little  more  than  login/logout  times  for 
users.  At  the  other  end  of  the  spectrum,  systems  running  at  an  Orange  Book  C2 
level  of  assurance  can  easily  generate  several  megabytes  of  log  information  per 
hour. 

To  detect  an  intrusion,  begin  by  examining  whatever  logs  are  available  on  your 
system.  Bear  in  mind,  however,  that  if  an  intruder  gained  access  to  your  system, 
the  information  stored  in  the  logs  may  have  been  modified  to  hide  the  intruder’s 
tracks.  Use  the  “last”  and/or  “lastcomm”  commands  discussed  in  the  next  two 
sections  (and  previously  described  above)  to  help  you  examine  the  logs. 


The  “last”  The  “last”  command,  available  on  almost  every  version  of 

Command  Unix,  displays  login  and  logout  activity  for  the  system. 

This  can  be  a  useful  place  to  begin  an  investigation.  Check 
the  login  times  and  locations  for  all  users  and  compare 
them  to  expected  norms.  Refer  to  the  previous  discussion  of 
the  “last”  command  for  more  information  and  a  sample 
output. 
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Finding  Files  and  Other  Evidence  Left  by  an  Intruder,  continued 


Inspecting 
Log  Files 


Inspecting 

Processes 


The 

“lastcomm” 

Command 

(Accounting) 


On  systems  with  process  level  accounting  enabled,  the 
“lastcomm”  command  will  generate  a  detailed  list  of  all 
commands  executed  by  each  user  on  the  system.  Unusual 
or  inappropriate  system  activity  can  often  be  discovered  in 
the  results  from  this  command.  For  example,  “lastcomm” 
output  indicating  repeated  executions  of  the  “tftp”  program 
might  indicate  attempts  to  steal  password  files  using  TFTP. 


For  information  on  enabling  process  accounting  on  a 
specific  Unix  system,  refer  to  the  man  page  for  “acct”. 
Refer  to  the  previous  discussion  of  the  “lastcomm” 
command  for  more  information  and  a  sample  output. 


Many  system  process  events  generate  messages.  For  example,  the  “su”  utility 
often  makes  a  log  entry  when  a  user  attempts  to  become  the  “super-user.”  These 
messages  may  prove  useful  in  discovering  unusual  activity  possibly  caused  by 
an  intruder. 

These  messages  are  often  archived  in  log  files  for  later  examination.  Commonly 
used  files  include  /var/log/syslog  and  /var/adm/messages;  however,  the  file 
names  may  vary  from  system  to  system.  Refer  to  the  sections  about  these  files 
in  this  guide  or  to  the  man  page  for  “syslog”  for  more  information. 


~/.history  Some  shells,  tcsh  for  example,  keep  a  record  of  the  most 

recently  executed  commands  for  each  user.  This 
information  is  usually  stored  in  a  file  in  the  user’s  home 
directory  and  is  often  called  “.history”.  Examining  this  file 
may  allow  the  reconstruction  of  the  recent  activities  of  a 
specific  user. 


Look  for: 

•  process  names  that  are  unfamiliar 

•  processes  using  an  unusual  amount  of  CPU  time 

•  processes  with  names  such  as  Crack  or  ypsnarf 

•  an  unusually  large  number  of  processes 
Keep  in  mind  that  process  names  can  be  changed. 
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Finding  Files  and  Other  Evidence  Left  by  an  Intruder,  continued 


Inspecting 

Targeted 

Files 


/etc/passwd  Look  for: 

•  new  accounts 

•  changed  uid 

•  no  password 

•  a“+::”entry 


■/.forward  The  -/.forward  file  is  used  to  manipulate  E-mail 

forwarding.  When  examining  this  file,  look  for  any 
suspicious  entries  (that  is,  would  it  make  sense  for  a 
legitimate  user  to  manipulate  his  or  her  E-mail  in  that 
manner?). 


-/.rhosts  and  The  -/.rhosts  file  can  be  used  to  allow  remote  access  to  a 
hosts.equiv  system  and  is  sometimes  used  by  intruders  to  create  easy 
backdoors  into  a  system.  If  this  file  has  recently  been 
modified,  examine  it  for  evidence  of  tampering.  Initially 
and  periodically  verify  that  the  remote  host  and  user  names 
in  the  files  are  consistent  with  local  user  access 
requirements.  View  with  extreme  caution  a  “-t”  entry;  this 
allows  users  from  any  host  to  access  the  local  system. 

An  older  vulnerability  is  systems  set  up  with  a  single  “-t”  in 
the  /etc/hosts. equiv  file.  This  allows  any  other  system  to 
log  in  to  your  system.  The  “-t”  should  be  replaced  with 
specific  system  names.  Note,  however,  that  an  intruder 
cannot  gain  root  access  through  /etc/rhosts  entries. 


/ftp  Files  Directories  which  can  be  written  to  by  anonymous  ETP 

users  are  commonly  used  for  storing  and  exchanging 
intruder  files.  Do  not  allow  the  user  “ftp”  to  own  any 
directories  or  files. 
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Finding  Files  and  Other  Evidence  Left  by  an  Intruder,  continued 


System 
Executables  in 
User 

Directories 


Determining  if 
System 
Executables 
Have  Been 
Trojaned 


/etc/inetd.conf 


/etc/aliases 


cron 


Copies  of  what  may  appear  to  be  system  executables  in 
user  directories  may  actually  be  an  attempt  to  conceal 
malicious  software.  For  example,  recent  attacks  have  made 
use  of  binaries  called  “vi”  and  “sed”,  two  commonly  used 
Unix  utilities.  However,  these  particular  binaries  were 
actually  renamed  intrusion  software  files,  designed  to  scan 
systems  for  weaknesses. 

System  binaries  found  in  unusual  locations  may  be 
compared  to  the  actual  executable  using  the  “cmp” 
command: 


Prompt  %  dtp  /home/ jdoe/sed  /usr/bin/sed 


SPI  or  Tripwire  must  be  set  up  before  an  exposure  in  order 
to  determine  if  your  system  executables  have  been 
Trojaned. 

Use  your  CD-ROM  to  make  sure  you  have  a  good  copy  of 
all  your  system  executables,  then  run  the  above  mentioned 
products  according  to  the  instructions  that  accompany  them 
to  create  a  basis  for  later  comparison.  Periodically,  run  SPI 
or  Tripwire  to  detect  any  modification  of  the  system 
executables. 


•  Print  a  baseline  listing  of  this  file  for  comparison. 

•  Look  for  new  services. 


•  Look  for  unusual  aliases  and  those  that  redirect  E-mail 
to  unlikely  places. 

•  Look  for  suspicious  commands. 


•  Look  for  new  entries  in  cron  tab,  especially  root’s. 

•  Look  at  each  user’s  table. 
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Finding  Files  and  Other  Evidence  Left  by  an  Intruder,  continued 


Looking  for  X 

windows 

intrusions 


/etc/rc* 


•  Look  for  additions  to  install  or  reinstall  backdoors  or 
sniffer  programs. 

•  Use  SPI  or  Tripwire  to  detect  changes  to  files. 


NFS  Exports 


Use  the  “showmount  -a”  command  to  find  users  that 
have  file  systems  mounted. 

Check  the  /etc/exports  (or  equivalent)  file  for 
modifications. 

Run  SPI  or  Tripwire  to  detect  changes. 


Changes  to  •  Run  SPI  or  Tripwire  initially  and  then  periodically. 

Criticai 

Binaries  *  Use  the  “Is -Ic”  command  to  determine  if  there  have 

been  inappropriate  changes  to  these  files. 

Note  that  the  change  time  displayed  by  the  “Is  -Ic” 
command  can  be  changed  and  the  command  itself  can  be 
Trojaned. 


X  windows  attacks  are  very  difficult  to  detect  because  of  a  lack  of  security 
features.  We  suggest  securing  X  systems  before  an  attack  occurs.  Refer  to  the 
CIAC  publication  Security  for  Unix  Systems  (UCRL-ID-118615  or 
CIAC-2306)  for  additional  information. 
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Appendix  A:  Software  Tools 


Introduction 


What’s  in  This  appendix  summarizes  the  features  and  locations  of  several  software 

This  packages  mentioned  in  this  document. 

Appendix 


Software  Tools 


Check  The  CPM  tool  provides  an  alternative  means  for  testing  the  status  of  a  network 

Promiscuous  interface  and  determining  if  it  is  in  promiscuous  mode,  a  symptom  of  possible 

Mode  (CPM)  sniffer  activity  on  the  system.  The  CPM  tool  is  of  most  use  in  cases  where  it  is 

suspected  that  the  standard  ifconfig  command  has  been  Trojaned. 

CPM  is  available  via  anonymous  FTP  from  info.cert.org  in  the  directory 
/pub/tools/cpm/. 


Security 

Profile 

Inspector 

(SPI) 


The  Security  Profile  Inspector  (SPI)  tool  performs  security  assessments  of 
Unix-  and  VMS-based  systems,  reporting  system  configuration  vulnerabilities, 
bad  passwords,  and  violations  of  system  file  integrity.  The  SPI  tool  will  also 
maintain  a  database  of  secure  checksums  for  specified  system  directories  and 
will  alert  the  administrator  to  any  changes  to  the  contents  of  those  directories. 

For  further  information,  call  the  SPI  project  lead  at  (510)  422-3881. 


Tripwire  The  Tripwire  tool  will  monitor  the  integrity  of  a  set  of  user-selected  files  and 

directories  on  a  Unix  system.  The  tool  will  detect  and  report  to  the  system 
administrator  any  changes,  additions,  or  deletions  to  these  files. 

Tripwire  is  available  via  anonymous  FTP  from  coast.cs.purdue.edu  in  the 
directory  /pub/tools/unix/Tripwire. 
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Appendix  B:  Contacting  CIAC 


Contacting  CIAC 


Phone 

(510)  422-8193 

Fax 

(510)  423-8002 

STU-III 

(510)  423-2604 

Eiectronic 

maii 

ciac@llnl.gov 

Emergency 

SKYPAGE 

800-SKYPAGE  pin#  855-0070 

Anonymous 
FTP  server 

ciac.llnl.gov  (IP  128.115.19.53) 

BBS 

(510)  423-3331  (9600  Baud) 
(510)  423-4753  (2400  Baud) 
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Reader  Comments 


CIAC  updates  and  enhances  the  documentation  it  produces.  If  you  find  errors  in  or  have 
suggestions  to  improve  this  document,  please  fill  out  this  form.  Mail  it  to  CIAC,  Lawrence 
Livermore  National  Laboratory,  P.O.  Box  808,  Mail  Stop  L-303,  Livermore,  CA,  94551- 
9900.  Thank  you. 

List  errors  you  find  here.  Please  include  page  numbers. 


List  suggestions  for  improvement  here. 


Optional: 

Name _  Phone 
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